Universal Mobile Telecommunication System (UMTS) is the third generation mobile communication system in which the radio technology adopts WCDMA, and its standardization efforts have been completed by the third generation partner project (3GPP) organization. So far four versions have been developed, i.e. Release 99, Release 4, Release 5 and Release 6. In Release 5, a new domain, i.e. an IP multimedia subsystem (IMS) domain has been introduced by UMTS core network on the basis of existing circuit switching (CS) domain and packet switching (PS) domain.
The IMS domain primarily provides IP multimedia services such as voice, audio and video that have high real-time requirements. According to 3GPP specification TS26.236, the user plane transport protocol of a session-type IP multimedia service in the IMS domain adopts the real-time media transport protocol defined by the Internet Engineering Technology Force (IETF): real-time transport protocol (RTP) and real-time transport control protocol (RTCP), as shown in FIG. 1. RTP is used for carrying real-time media coding data, while RTCP is used for periodically transmitting such information as quality parameters of the media transmission. RTPRTCP runs above the user datagram protocol (UDP), wherein RTP streams use even-numbered UDP ports, while the corresponding RTCP streams use adjacent odd-numbered UDP ports. As to a detailed description of RTP and RTCP, see IETF document RFC1889.
A typical RTP header is 12 bytes in length, a typical UDP header is 8 bytes in length, a typical IPv4 header is 20 bytes in length, and a typical Ipv6 header is 40 bytes in length. Therefore, an RTPUDP/IPv4 packet header is 320 bits in length, while an RTP/UDP/IPv6 packet header is 480 bits in length. In addition, the length of the RTP payload is usually relatively short in length. As shown in FIG. 1, the RTP payload consists of the header and media coding data. Taking a VoIP service employing an adaptive multirate (AMR) voice codec in the IMS domain as an example, the format of its RTP payload follows IETF standard RFC3267. According to the mode parameters of the employed payload format and rates of the AMR voice codec, etc., the length of AMR voice RTP payload in the IMS domain is about 14 to 34 bytes. It is apparent that, the header overhead of the RTP/UDP/IP packet is large, and directly transmitting them on the radio interface will greatly reduce channel efficiency. Therefore, an effective header compression algorithm is desirable to improve transmission efficiency of the radio interface.
A robust header compression (ROHC) algorithm specified by IETF standard RFC 3095 is employed in UMTS to achieve the header compression of the RTPRTCP packet of the IP multimedia service in the IMS domain. ROHC is an effective RTP/UDP/IP and UDP/IP (for example, RTCP, etc.) header compression algorithm designed for long round trip time (RTT) and high bit error rate of the radio link. In ROHC, three compression states having different compression efficiencies are defined, i.e. IR, FO and SO. In the IR state, a compressing end transmits a static and/or dynamic field of the packet header to a decompressing end, so as to create or update a context between the compressing end and decompressing end. In the SO state, the compressing end and the decompressing end have reached a reliable synchronization between them, the change in headers of successive packets is completely predictable, thus it is possible to achieve the highest compression rate. The FO state is such a compression state that its compression rate lies between IR and SO, in which state a small number of packet header fields change irregularly, as a result, the compression rate thereof is lower than that of the SO state. In addition, depending on the difference of one-way/two-way channel and of the way of triggering the compression state migration, the ROHC algorithm has three different operating modes, i.e., U, O and R. As shown in FIG. 2, the ROHC operation always starts from the U mode, and thereafter transfers to the O mode or R mode depending on different feedback information. The U operating mode does not utilize feedback information from the decompressing end, but only achieves the synchronization of the context between the compressing end and the decompressing end by periodically returning to a lower compression rate state from a higher compression rate state. Both O and R modes need the feedback information from the decompressing end, and returning to the lower compression rate state from the higher compression rate state is based on a negative acknowledgement (NACK) from the decompressing end. However, in the O operating mode, the way of migrating to the higher compression rate state from the lower compression rate state is similar to the U operating mode, that is, based on an optimistic judgement of the compressing end that the decompressing end has taken the information on the context, while in the R operating mode, migrating from the lower compression rate state to the higher compression rate state is still based on the feedback information from the decompressing end, i.e. an acknowledgement (ACK) reply of the decompressing end. Therefore, the R operating mode has the highest reliability, but its channel overhead is slightly higher than the other two modes due to an increase in the feedback information.
In the ROH protocol, due to differences in the operating modes and compression states, the header-compressed packets, transmitted from the compressing end to the decompressing end, include Packet Type 0 (UO-0, R-0, R-0-CRC), Packet Type 1 (R mode: R-1, R-1-TS, R-1-ID), Packet Type 1 (UO mode: UO-1, UO-1-TS, UO-1-ID), Packet Type 2 (UOR-2, UOR-2-TS, UOR-2-ID), etc., and the packets transmitted from the compressing end to the decompressing end for initializing/updating the context have two types: IR and IR-DYN, and the packets fed back from the decompressing end to the compressing end have such types as Feedback-1 and Feedback-2, etc. Even for packets of the same type, many factors (such as an extended field, a checksum field of UDP, an ROHC segmentation processing, and feedback type packet) will render their length uncertain. Therefore, the header size of an ROHC header compressed packet varies in a wide range from the shortest one byte to slightly larger than the entire header length, but the length of most compressed headers is small.
FIG. 3 shows the architecture of a UMTS radio access network (UTRAN), wherein radio network controllers (RNCs) are connected to the core network via Iu interfaces, the RNCs are interconnected via an Iur interface, and an RNC is connected to one or more Node B's via an Iub interface. One Node B comprises one or more cells which is an elementary unit of radio access for a user equipment (UE), wherein a radio interface between UE and UTRAN is a Un interface.
FIG. 4 shows the structure of a UMTS radio interface protocol, wherein the bottom layer is a physical layer (PHY). In the control plane, layers above the physical layer are the media access control (MAC)layer, the radio link control (RLC) layer and the radio resource control (RRC) layer, respectively. The user plane radio interface protocol consists of a physical layer, a MAC layer, an RLC layer and a packet data convergence protocol (PDCP) layer, wherein the PDCP layer is used only for the PS domain, it improves the frequency spectrum utilization ratio of the radio transmission by means of header compression and provides a radio bearer (RB) service for an upper layer. The physical layer provides a physical channel; the channels between the MAC layer and the physical layer are transport channels, and a plurality of transport channels may be multiplexed into one physical channel. The channels between the MAC layer and the RLC layer are logical channels, and a plurality of logical channels may be multiplexed into one transport channel via the MAC layer.
According to 3GPP specification such as 3GPP TS25.212, 3GPP TS25.302, a transport format indicator (TFI) accompanying each transport channel corresponds to a transport format in a transport format set (TFS) of the transport channel. In each transport time interval (TTI), as shown in FIG. 5, the upper layer transmits transmission blocks (TB) of each transport channel to the physical layer according a certain transport format combination (TFC). The physical layer combines the TFI information from different transport channels into a transport format combination indicator (TFCI) and transmits it in a TFCI field of the physical channel after it is encoded, and the receiving end can correctly receive each transport channels by decoding the TFCI field. Here, a set consisting of transport format combinations (TFCs) of different transport channels is referred to as a transport format combination set (TFCS). In general, due to limitations on TFCS coding bits and reliability requirement, TFCS cannot be too large, in particular, when a downlink share channel (DSCH) is accompanied and a hard split mode TFCI coding is used, the available TFCI coding bits can only be 5 bits, thus the largest permissible TFCS does not exceed 32.
In UMTS, the RLC protocol provides segmentation and retransmission services for user and control data. Depending on different application requirements, RLC supports three operating modes: transparent mode (TM), unacknowledged mode (UM) and acknowledged mode (AM). Table 1 lists functions of the three operating modes of the RLC protocol. The TM mode RLC layer does not add any header overhead, thus is adapted to a delay-sensitive session type real-time service, and its segmentation and reassembly functions require that SDU (service data unit) be an integer multiple of PDU (protocol data unit) in length. UM and AM modes have concatenation, padding, segmentation and reassembly functions. Therefore, regardless of the length of SDU, SDU can be divided into PDUs of fixed lengths for transmission on the radio channel. In contrast, the AM mode also supports an automatic retransmission request (ARQ) function, it provides a transmission capability of low bit error rate at the cost of delay increase. Therefore, the AM mode is primarily used for non-real-time packet type service, while the UM mode is primarily applied to time-critical stream type real-time service.
TABLE 1MODEFUNCTIONTMSegmentation and reassembly(TransparentSDU discardMode)Transfer of user dataUMSegmentation and reassembly(UnacknowledgedConcatenationMode)PaddingTransfer of user dataCipheringSequence number checkSDU discardAMSegmentation and reassembly(AcknowledgedConcatenationMode)PaddingTransfer of user dataError correctionIn-sequence delivery of upper layerPDUsDuplicate detectionFlow controlProtocol error detection and recoveryCipheringSDU discard
According to 3GPP specification TS23.107, each UMTS bearer service consists of a radio access bearer (RAB) service and a core network bearer service, and the radio access bearer service consists of an lu bearer service and a radio bearer (RB) service. In a schematic diagram showing an instance of a structure of the PDCP layer in FIG. 6, each PDCP entity 60-62 provides a radio bearer (RB) for the upper layer, i.e. one RB corresponds to one PDCP entity, and each PDCP entity can use 0, 1 or a plurality of header compression algorithms according the configuration. Only two types of header compression algorithms are supported in the present protocol version, i.e. RFC 2507 (IPHC) and RFC 3095 (ROHC), wherein IPHC is primarily applied to a non-real-time packet service based on TCP/IP, etc., while ROHC is applied to a realtime packet service based on RTP/UDPIP, etc. Besides the header compression function, the PDCP layer also has a SDU sequence number maintaining function so as to support a relocation function of a lossless source radio network subsystem (SRNS), but this function requires the use of AM mode RLC to provide a sequential delivery function and thus is primarily applied to the non-real-time packet service. The 0, 1 and 3 bytes added respectively on the basis of the header-compressed packet output by the header compression algorithm (IPHC, and ROHC, etc.) in the PDCP protocol form three PDCP layer PDU formats, i.e. PDCP-No-Header PDU, PDCP Data PDU and PDCP SeqNum PDU, as shown in FIG. 8, wherein the PDCP SeqNum PDU has a sequence number field for supporting the relocation function of the lossless SRNS.
According to 3GPP TS23.228, TS23.207, TR21.877, application level signalling and media data of the session type real-time IP multimedia service in the IMS field generally use a separated UMTS bearing channel so as to ensure the desired quality of service (QoS) of the application level signalling (for example, SIP-session initiation protocol). Different types of media data streams generally use separated UMTS bearing channels for transmission due to significance differences in the Qos requirements. The same type of media data stream consists of RTP/UDP/IP and RTCP/UDP/IP packets, and can be transported on the separated or the same UMTS bearing channels. For the same type of media RTP/UDP/IP packet, as described in 3GPP documents such as “Tdoc R2-001422, Status of the ROHC WG in IETF and Response to Questions from RAN WG2”, the RTP payload and the compressed header may be transported on different radio links, so as to provide better protection for the compressed header. In addition, for IMS services such as AMR or AMR-WB (wideband AMR), TR21.877 also gives some possible signalling modes for delivering the RTP payload format information, including an RTP payload header, media data bits of different error sensitivities (for example, A/B/C type bits in an AMR voice), to the RNC during signalling stages such as service call setup, such that it is possible to further apply an non-equal error protection (UDP) mechanism to the RTP payload.
As described before, for the session type real-time IP multimedia service in the IMS domain, the PDCP layer employs the ROHC header compression algorithm to improve transport efficiency of the radio interface. However, the header of the ROHC header compressed packet (including overhead bytes added in the PDCP layer) has a header size varying in a wide range from the shortest one byte to slightly larger than the entire header length. In addition, due to the real-time requirement on the session type IP multimedia service in the IMS domain, only TM or UM mode RLC can be adopted. However, due to the following reasons, it is difficult for the two RLC modes effectively and directly to support transmission of PDCP layer PDU which uses ROHC header compression and has a high real-time requirement:    1) The TM mode does not support the padding function but can only transports the upper layer PDU transparently. However, the header size of the ROHC header-compressed packet from the upper layer is changeable in a wide range, thus a huge TFS must be employed to cover all the possible packet header sizes, which reduces the reliability of the TFCI decoding and complicates the physical layer processing.    2) Although the UM mode supports the padding function, the current protocol does not have specific signallings and methods to dynamically control concatenation, segmentation and reassembly functions under the UM mode, as a result, delay inevitably increases. In addition, when UEP mechanism for separately transporting the compressed header and the RTP payload is used, since RTP payload rate is constant but a compressed header rate is variable, a synchronization problem between them occurs.